Embodiments of the present invention relate generally to methods and systems for filtering a complex dataset and to using a filter implemented as a single, re-usable component of a user interface to specify and perform filtering on a complex dataset.
Various types of applications such as enterprise applications, for example, utilize datasets that can be considered complex. That is, these datasets can include not only data but can also include or be arranged in a hierarchy. Additionally, these applications typically provide mechanisms for filtering the dataset based on user defined criteria in order to generate reports or otherwise provide data from the dataset to the user based on the criteria. For example, in past releases, Oracle Applications and PeopleSoft Enterprise application solutions had numerous user interface solutions to support filtering of datasets in order to specify simple to complex ranges of values. Particularly, such solutions were used to specify filters on a dataset called Chart of Accounts (COA). In Oracle e-Business Suite and Fusion Applications, the Accounting Flexfield is the name for the list of segments and account values that make up the chart of accounts. In PeopleSoft Enterprise, ChartFields is the term used to mean the COA.
The Chart of Accounts is the underlying structure for organizing financial information that impacts many areas, such as transaction processing, reporting, analytics, and internal controls. The list of accounts can be numerical, alphabetic, or alpha-numeric. For example, to denote the type of travel expenses incurred by an organization, one could define an account for meals expenses to 6120, lodging 6130, airfare 6150, etc. Then, to identify which department or line of business incurred those expenses, one could define another set of department accounts, such as Sales to be department value 1A0, Marketing to be 2A0, Finance to be 3B0 to, R&D to be 4B0, and so on. Many companies (customers) will use other segments in their COA to identify other aspects of their business and transactions, such as company, product line, and region that incurred a particular expense or revenue. By organizing the COA this way, it helps to identify the nature of transactions during transaction processing, reporting, analytics, and so on. The filtering mechanism seeks to identify one to many results from a COA based on a set criteria (segments, conditions, and segment values) entered.
However, past filtering mechanisms were subject to several significant limitations. For example, past filtering mechanisms were custom and multiple solutions were needed to provide filtering on the COA depending on what needed to be achieved, e.g., navigating and filtering across trees, ranges and/or values. Additionally, past filtering mechanisms were hard to leverage across different products as different UI solutions were needed for different filtering needs. Furthermore, past filtering mechanisms involved complex user interface solutions, even for simple filters, which were difficult to use and hard to interpret by those users not familiar with the interface. Past filtering mechanisms used complex syntax and terminology for input and description of the filter. Also, past filtering mechanisms showed all required and optional fields from the data set making it harder and slower to enter just what data is needed. Hence, there is a need for improved methods and systems for specifying and performing different types of filtering on a complex dataset.